A VPN service comprises a service between a plurality of devices acting as service end points which are managed by a manager such as a service manager including a service station for a network administrator. The service end points are connected over any appropriate medium. For example the service end points can comprise clients connected over the internet. Any number of service end points can belong to a virtual private network. Any individual device can belong to multiple disparate virtual private network services acting as a discrete service end point for each service.
For a service provider, an essential part of the provisioning process for VPN services such as layer 2 Ethernet VPN services is to determine that once any necessary changes have been made to the network elements, the service is operational. Traditionally, this requires either a management system to perform some form of connectivity test between the service end points, or for a manual test to be carried out. In the case of services such as layer 2 Ethernet services, this is further complicated by the fact that there is currently no consistently available mechanism for testing connectivity at the Ethernet layer. Hence a layer 3 overlay is often introduced purely for the purpose of verifying reachability.
For example in the case of the IEEE 802.1ag Draft 7 protocol, a description of which is available at the time of this writing in the file “820.1ag.html” in the folder/1/pages/of the domain ieee802.org on the World Wide Web, this provides mechanisms to detect and troubleshoot service effecting faults within a network such as a Metro Ethernet network of the kind described, at the time of writing in “Metro Ethernet Forum Specification MEF 4, Metro Ethernet Network Architecture Framework—Part 1: Generic Framework.”
In one approach a service end point sends a protocol dependent message such as “service up” or “no defect” in any appropriate protocol such as simple network management protocol (SNMP) and the management station marks the end point as “up”. If a message is not received from an expected end point within a specified time period then it is considered faulty and provisioning has failed. Conversely, if messages are received from all end points within a service within the time period, the service is considered healthy and provisioning is considered to have succeeded.
In both cases events are generated at the end points in the form of SNMP notifications to inform the management station of the status which may be “service up” or “missing end-point” as appropriate. However the management station is only able to report the status from the perspective of each end point—not for the overall service.
As a result the management system must have intimate knowledge of the provisioning operations in order to form the subsequent post-provisioning tests. For example the management system needs to know the network elements, the VLANs (virtual local area networks), ports and access credentials in order to contact the service end points. This further complicates the process because of the additional overhead placed on the management system. Existing solutions to this type of problem require explicitly testing the service using standard tools such as “ping” and “trace” which must be activated and coordinated by a network management system, or performed manually.